Three Dimensions of Design Development

Formal specifications are difficult to understand for a number of reasons. When the developer of a large specification explains it to another person, he typically includes mformatlon in his explanation that is is not present, even Implicitly. in the specification itself. One useful form of information presents the specification In terms of an evolution from simpler specificattons. TypIcally a specification was actually produced by a series of evolutionary steps reflected in the explanation. This paper suggests three dimensions of evolution that can be used to structure specification developments: structural granularity, temporal granularity. and coverage. Their use in a particular example is demonstrated. 1. Int reduction When we describe system behaviors to other people outside the confines of a formal language. it is common to find an evolutronary vein in the description. The final behavtor can be viewed as an elaboration of some simpler behavior. itself the elaboration of a yet simpler behavior. etc.. back to some behavior deemed sufficiently simple to be comprehended from a non-evolutionary description. Formal specifications can likewise be described in an evolutionary vein. More importantly, the evolutionary steps can be characterized in terms of the kind of change they make to the specification. Three orthogonal dimensions of evolution have been Identified. l structural granularity -deals with the amount of detail the specification reveals about each individual state of the process. * temporal granularity -deals with the amount of change between successive states revealed by the specification. * coverage -deals with the range permitted by a specification. of possible behaviors Development steps along these dimensions can be composed to produce desired changes to a specification. This gives some This research was supported by Defense Advanced Research Projects Agency contract MDA903-81 C-0335. Views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official opinion or policy of DARPA, the U.S. Government, or any other person or agency connected with them. hope that the steps themselves can be formalized -i.e., that a language of change can be developed that permits a formal specification to be viewed and analyzed from its evolutionary perspective. 2. Specifications and Processes A “formal specification” is something which denotes, according to well-defined rules, a set of behavrors. This set will be termed the process denoted by the specification. A behavior IS a sequence of states. Each state comprises a set of oblects and a finite set of relations. A relation IS a set of n-tuples over the objects. A state models an instantaneous snapshot of a situation occurring during a particular execution of the process. A behavior then models the temporally ordered sequence of situations that constitutes a particular execution of the denoted process. 2.1. Initial Decisions In order to specify some desired or existing activity within this framework, it is necessary to make certain (tentative) decisions about what aspects of the activity are to be specified. These decisions need not encompass all aspects of the activity. The goal at this initial stage IS to specify enough of an abstraction of the activity to distinguish some of the relevant objects and actions involved. but not so much detail that the abstraction itself IS difficult to write or comprehend. Let us explore these considerations in the context of a particular example. a specification of the game of baseball. To structure our initial design. we consider three dimensions along which initial decisions must be made. One decision to be made concerns an tnittal structural granularity for the specification. This amounts to deciding what information about a particular situation is to be encoded in a state -i.e., what objects and relations are to be represented. The jargon of any particular domain generally gives many possibilities. In baseball, we talk about concrete objects like players, coaches, managers, umpires, bases, balls, bats, as well as more abstract concepts like teams, positions, and scores. Since baseball is a game, a minimally interesting formalization will have to capture the notion of the participants and scoring. So let us make our initial goal be to encode in each state only the score of each of the two teams in the game. A second consideration concerns an initial temporal granularity for the specification. In this case, the jargon of baseball suggests several possibilities. One could take a snapshot after every pitch, or batter, or out, or half-inning, or inning, or just at the start and finish of the game. Our goal of keeping things simple suggests a 130 From: AAAI-83 Proceedings. Copyright ©1983, AAAI (www.aaai.org). All rights reserved. rule of thumb: start with the coarsest temporal granularity that suggests itself. In this case, that corresponds to making our initial goal be to let each state transition in a behavior cover a single inning of the game. The third consideration concerns the behavioral coverage of the specification. One might aim for all possible complete games of baseball, or might choose to include possible cancelled or suspended games as well. The simplicity goal suggests another rule of thumb: start with coverage of normal cases only. In this case, that corresponds to making our initial goal be to include in the denoted process only complete, ninesinning games. 2.2. Development Decisions One’s initial version of a specification (or program) is an approximation, often a very crude one. to what is desired or achievable [3]. Traditionally. one refines the denoted process by altering the specification -inserting. deleting, and replacing textual units of specification. In recent years, researchers have argued that viewing the development of a specification as a flat sequence of textual changes hides structure that directs those changes. Waters [4] and Barstow [2] show that many seemingly complex alterations are implementation idioms of a given language. Wile [5] allows the alterations to be grouped within a hierarchical goal structure reflecting meaningful concerns of the implementer. Structured developments are easier to comprehend and, it is argued, raise the level of expression available to the designer in a way that leads to gains in productivity. This paper demonstrates that the same three dimensions of decision used to obtain an initial specification can be used to structure the development of that specification. A decision to specify greater detail about each state of a process is a refinement in the structural granularity dimension. Such a refinement leads to a new process and a many-to-l mapping from the behaviors of the new process to those of the old. A new behavior has states in 1 1 correspondence with the states of the corresponding old behavior, but containing more objects and/or relationships. Conversely, a decision to specify less (“hide”) detail about each state is an abstraction in the structural granularity. A decision to reveal more of the individual state transitions of a process is a refinement in the temporal granularity dimension. Such a refinement leads to a new process and a many-to-l mapping from the behaviors of the new process to those of the old. A new behavior contains its corresponding old behavior as a subsequence. Conversely, a decision to specify less (“hide”) detail about state transitions is an abstraction in the temporal granularity. A decision to add additional possible behaviors to a specification IS an expansion in the coverage dimension Such a refinement leads to a new process whose behaviors are a superset of those specified previously. Conversely. a decision to remove possible behaviors is a contraction in the coverage. It will become apparent that, even in the simple example used in this paper, meaningful (in domain terms) changes to a specification do not constitute changes along a single one of these dimensions. However, it is demonstrated that meaningful changes can be represented as sequences of changes each along a single dimension, and that these representations could be useful both as explanations of specification development and as the means of specification development. 3. Baseball: an example The initial specification of baseball appears in figure 3-1. Paraphrased. this speciftcation says: There are two teams, called home and vwtor. Each team has exactly one Score. which is 0 or more. Each team starts with a score of 0. A game consists of nine sequential innings. An inning is the net effect of each team batting once. The effect of a team batting is to leave the score unchanged or to increment the team’s Score by some (integral) amount. In this specification. the particular above have been made explicit. granularity decisions discussed The notation used here to represent formal specifications is called Gist [I]. Understanding this notation in detail is not important. The point of the development that follows is that the textual changes to this notation effect. but do not clearly convey to a person, the nature of the change being made to the denoted process -in this case, baseball. The changes to the process are described informally in terms of the three dimensions discussed above. This provides an alternative, and, it is claimed, preferable view of the development. There are several directions in which one might choose to elaborate this definition of baseball. In particular, we might choose either to provide a more detailed definition of those baseball games which are included in the collection just defined, or we might try to define a more accurate set at the same level of detail. Let us start in the latter direction. Behaviors from STATE ==> visitor:Score = home:Score = 0 ACTIVITY ==> Pl ayBall( ) agent TEAM( Score j non-negative-integer) definition {home, visitor} where action Bat() definition self :Score :+= a non-negativeinteger ; action PlayBall () definition 9 times do PlayInning ; action PlayInning () definition begin atomic Bat0 by visitor; Bat() by home end atomic Figure 31: Initial Specification -g-inning game 3.1. Rule Out Tie Games One thing we want to convey is that baseball games do not end in a tie. In development terms, this is a contraction in coverage _. we wish to restrict our specification to a subset of the currently specified behaviors. In Gist, contraction is often accomplished by adding a constraint. In this case. a postcondition on the overall activity will suffice (see figure 3-2). This might be paraphrased by: The game must end with the two teams having different scores. Behaviors from STATE ==> visitor:Score = home:Score = 0 ACTIVITY ==> Pl ayBall( ) postcondition visitor:Score f home:Score Figure 3-2: Rule Out Tie Games 3.2. Extra Inning Games We now have a more accurate, though not yet “correct”, specification of nine-inning games. As a next step we could further refine this set, or, what seems more natural, introduce the concept of extra-inning games. This is a coverage expansion step, which might be paraphrased by: Actually, a game consists of at least nine innings, but will continue after that until an inning terminates with the score not tied. One way to achieve this in Gist is with the change depicted in figure 3-3. action PlayBall () definition until NormalTermination() do PlayInning( ): relation NormalTermination() definition Inning(*) 2 9 and visitor:Score f home:Score; relation Inning( Ilnon-negative-integer) definition I = count start PlayInning() Here, then, is a case of subgoaling in the development. The primary goal is to contract the specification to a subset of behaviors. The means for achieving this requires refining the temporal granularity of the description. As a first step, we make an inning a sequential event (see figure 3-4), paraphrased as: Actually, an inning consists of fmt having the visiting team bat, and then having the home team bat. action PlayInning () definition begin sequential Bat0 by visitor; Bat0 by home end sequential Figure 3-4: Half Inning Granularity Following this refinement, each behavior has two state transitions per inning rather than one. The key effect of this refinement IS to provide half-inning updates of the score, making it simple to state the condition under which the home team does not bat, the key to achieving the needed contraction of the behavior. This can be accomplished in the specification text by conditionalizing the event (see figure 3-5), paraphrased as: The home team’s turn at bat is skipped in the ninth inning if it is ahead. action PlayInning () definition begin sequential Bat0 by visitor: if Inning(S) and home: Score > visitor:Score then null else Bat() by home end sequential Figure 3-3: Extra Inning Games Figure 3-5: Skip Home Ninth 3.3. One Team Bats at a Time The behaviors defined now include all “normal” (barring war, riot, and natural disasters) complete baseball games but still constitute too large a set. Among games that must be excluded are those in which the home team scores in the ninth inning when it had enough runs to win after eight innings. For example, a home team cannot lead 2-l after the eighth inning and end up winning the game by a 5-l score. The desired coverage contraction on the currently defined process could be accomplished by strengthening the termination condition. An English paraphrase of the condition would be: . . . and, if the home team wins, then either (a) it scored no runs in the ninth inning. or (b) its score at the start of the ninth inning was no greater than the visiting team’s score at the end of the ninth inning. It seems absurd that anyone would choose to refine the description this way. The reason is that this is not a rule (axiom) of baseball as most people understand the game; rather it is a property (theorem) that follows from rules that are far more simply stated. To state these rules, however, requires a major refinement in the description; it will no longer suffice to think of an inning as an atomic event. 3.4. One Player Bats at a Time Alas, the revised description still contains too many games. The problem is that, when the home team bats in the ninth inning or thereafter, it is not allowed to score an arbitrary number of runs, as it is in a normal inning. But now we are up against a problem we have just faced. The desired subset of behaviors is difficult to describe at the half-inning granularity; we would have to say something akin to: In the ninth inning and following innings, the home team may not score more runs than required to give it a margin of victory of four. As before, this property sounds absurd as stated. It is more naturally thought of as a theorem following from rules stated more simply at a finer temporal granularity. Half-innings are not atomic events to someone who understands baseball. but are composed of an iteration of smaller events. In each of these smaller events, the batting team’s score is incremented by at most four. Within this finer temporal granularity, the desired behavior subset is achieved by adding a simple mandatory termination exception. depicted in figure 3-6, to the home team’s Bat event: